Method and apparatus for reporting emergency incidents

ABSTRACT

An event reporting program ( 48 ) is provided which electronically records information critical to reconstructing events occurring during an emergency incident. The event reporting program ( 48 ) includes an event recording component ( 204 ) for recording events as they occur during the incident, and a post-processing component ( 206 ) for further processing the events recorded by the event recording component after completion of the incident. The event recording component ( 204 ) enables an emergency service provider to input a plurality of event records ( 148 ) describing each event as it occurs and the time at which each event takes place. The event recording component also enables an emergency service provider to input a predefined protocol of expected event records.

[0001] This application claims priority from U.S. application Ser. No.09/152,837, filed Sep. 14, 1998, the entire content of which isincorporated herein by reference

FIELD OF THE INVENTION

[0002] This invention generally relates to a method and apparatus forallowing a trained emergency service provider to report emergencyincidents and, more specifically, a method and apparatus for allowing anemergency service provider to electronically collect and recordinformation regarding an emergency incident and generate a meaningfulreport of such data.

BACKGROUND OF THE INVENTION

[0003] Emergency care is commonly delivered to a patient at the scene ofan incident by trained emergency service providers such as paramedics,police officers, emergency medical technicians (EMTs), etc. Theseproviders work within a community-based Emergency Medical System (EMS)under the supervision of a medical director who establishes operatingprotocols, oversees training, and monitors the system's effectiveness.System effectiveness is assessed primarily by evaluating patientoutcomes, often through secondary measures that are closely associatedwith long-term survival such as response time, protocol adherence, andtime to delivery of effective therapy. Typically, such information isrecorded manually by the emergency service provider in a paper runreport including a patient information portion for recording personalpatient data, a narrative portion for recording the emergency serviceprovider's clinical narrative, and an event log portion for recordingeach of the treatment events that take place during the incident andtheir associated times of occurrence. Consequently, the report capturesthe time interval for the EMS to respond to the call for help, thepatient's presenting signs and symptoms, the delay until therapy isapplied, etc. The run report can then be later used to producestatistical summaries of overall EMS response characteristics. Oneexample of a statistical analysis report based on a run report is theUtstein Style report for measuring response effectiveness in cases wherethe patient has suffered cardiac arrest.

[0004] In order to generate incident run reports and statisticalsummaries such as the ones specified by the Utstein Style, raw eventdata must reliably collected, coded, and entered into a database. Often,the sources of raw event data are widely dispersed. Dispatch eventinformation is provided by a Computer-Aided Dispatch (CAD) system, whilevital signs and therapeutic information events are found in medicaldevices used on-scene during patient treatment. Emergency serviceprovider narratives are often written into run reports produced afterthe incident is concluded. It is difficult for any EMS system to collatethese disparate pieces of information into a single database. Often thesequence of events and their exact times can only be approximated fromthe records. The event log recorded in the run report can be especiallyinaccurate, since it is often compiled after-the-fact, perhaps dayslater, from memory and written notes. Efforts to introduce electronicversions of paper run reports for on-scene event capture have not beensuccessful because the equipment is bulky and expensive, its useinterferes with patient care, and the menu-driven database interfacefails to capture the full range of essential events needed. A particularfailing is that the accurate event times are not recorded along with theevents themselves, making calculation of response intervals inaccurate.

[0005] In order to more accurately record information critical toreconstructing incident events accurately, a more versatile, focusedapproach to electronic data collection for run reports is needed. Theapproach should provide for recordation of simple backgroundinformation, such as the patient's name and the incident location, aswell as a summary of each event that occurred during the emergencyincident and the particular time of the event. To be useful, theassociated time should be accurate to within one minute. Finally, theapproach should provide for capture of a clinical narrative by theemergency service provider which is the provider's account of theincident, including the provider's subjective appraisal, objectivefindings, and the assessments performed, and the provider's plannedtherapies and procedures. The approach should collect all of thisinformation, and merge the information with CAD and medical device datato populate the database needed for incident reporting and assessment ofsystem effectiveness.

SUMMARY OF THE INVENTION

[0006] The present invention provides a computer-readable medium havingcomputer-executable components for recording and reporting an emergencyincident comprising a plurality of events associated with treatment of apatient during the incident. The computer executable components includean event recording component and a post-processing component. The eventrecording component records events as they occur during the incident,while the post-processing component further processes the eventsrecorded by the event recording component once the incident hasconcluded.

[0007] The event recording component records events by enabling aemergency service provider to input a plurality of event records,wherein each event record identifies an event which occurred during theincident and a time at which the event occurred. The event recordingcomponent also records events input by the emergency service provider asa predefined treatment protocol for the patient, wherein the predefinedtreatment protocol comprises a plurality of predefined event records andwherein each predefined event record identifies an event which isexpected to occur during the incident and a time at which the event isexpected to occur during the incident. Finally, the event recordingcomponent includes at least one subcomponent for providing informationregarding the incident in addition to the event records recorded by theevent recording component. The subcomponent may be an address bookcomponent, a drug guideline component, a medication identificationcomponent, a narrative story component, a stop watch component or a drugdosage/infusion component.

[0008] The post-processing component, on the other hand, enables theuser to modify the event records previously recorded by the eventrecording component, as well as record additional information regardingthe incident. In addition, the post-processing component incorporatesevent records recorded by an external source, such as a remote computeror medical electronic device, with the event records previously recordedby the event recording component. The post-processing component alsoexports event records to external devices, such as a remote computer,for further processing and record-keeping. Finally, the post-processingcomponent generates a run report containing event records and relatedinformation recorded and processed by the event recording component andthe post-processing component.

[0009] In accordance with yet other aspects of the present invention,the event recording component and the post-processing component enablethe user to verbally input event records and related information.

[0010] A method and apparatus capable of performing actions generallyconsistent with the event recording component and the post-processingcomponent described above represent further aspects of the presentinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The foregoing aspects and many of the attendant advantages ofthis invention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

[0012]FIG. 1 is an isometric view of a hand-held computer that isinstalled with an event reporting program formed in accordance with thepresent invention to record and report an emergency incident;

[0013]FIG. 2 is a schematic block diagram of the several components ofthe hand-held computer shown in FIG. 1, that are used to implement theevent reporting program and record and report emergency incidents inaccordance with the present invention;

[0014]FIG. 3 is a flow chart illustrating the logic used by the eventreporting program to record and report emergency incidents;

[0015]FIG. 4 depicts an initial incident reporting window produced bythe event reporting program for recording incident identificationinformation;

[0016]FIG. 5 is a flowchart illustrating the logic used by the eventreporting program to record events and related information during theemergency incident;

[0017] FIGS. 6A-6L are various windows produced by the event reportingprogram for recording events and related information during theemergency incident;

[0018]FIG. 7 is a flowchart illustrating the logic used by the eventreporting program to further process events and related informationafter the occurrence of the emergency incident;

[0019] FIGS. 8A-8F are various windows produced by the event reportingprogram for further processing events and related information after theoccurrence of the emergency incident; and

[0020]FIG. 9 is a flowchart illustrating the logic used to parse aclinical narrative previously recorded by the emergency provider forcertain pertinent information.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0021]FIG. 1 illustrates a hand-held computer 20 used to record andreport emergency incidents in accordance with the present invention.More specifically, the hand-held computer 20 shown in FIG. 1 isinstalled with an event reporting program 48 formed in accordance withthe present invention to electronically record and report emergencyincidents. The hand-held computer 20 comprises a touch screen display 32for displaying the windows produced by the event recording program 48 ofthe present invention to prompt an emergency service provider to recordevents and related information that occur during an emergency incident.In order to record information and events, the emergency serviceprovider selects options provided by the displayed windows using a touchscreen pen 22. In addition, the emergency service provider may recordinformation and events using a keyboard 30. In yet other embodiments ofthe present invention, the hand-held computer 20 includes aspeaker/microphone 24 and appropriate voice recognition software forrecognizing voice commands and recording the voice input of events andinformation. Those of ordinary skill in the art will appreciate thatsuch voice recognition software is readily available off-the-shelf andcan be installed on the hand-held computer in addition to the eventreporting program 48. Further, the hand-held computer 20 may be equippedwith a high quality digital data recorder and a noise cancelingmicrophone in order to allow for better usage of the event reportingprogram in typically noisy and turbulent EMS field situations.Consequently, the emergency service provider can control the eventreporting program 48 and record events and related information merely byspeaking, rather than using a more traditional user input device such asa mouse, keypad, or touch screen/pen, etc. As a result, the emergencyservice provider has the free use of his or her hands to treat thepatient at all times and need not interrupt treatment to operate theevent reporting program 48.

[0022] Those of ordinary skill in the art will recognize that although ahand-held computer 20 is depicted in FIG. 1, the event reportingsoftware program 48 of the present invention can be installed andimplemented on any type of portable data entry system, including but notlimited to, a laptop computer, a personal device assistant, or even amedical electronic device such as a defibrillator. In addition, theportable data entry system may implement any type of user input devicesuch as a mouse, keypad, touch screen, microphone, wireless headset,etc. to input events and related incident information. In yet otherembodiments, the event reporting program 48 may be installed on a morestationary computer system, such as a personal computer or workstation.

[0023]FIG. 2 depicts several of the key components of the hand-heldcomputer 20. It will be appreciated by those of ordinary skill in theart that the hand-held computer 20 includes many more components thanthose shown in FIG. 2. However, a disclosure of an actual embodiment forpracticing the present invention does not require that all of thesegenerally conventional components be shown. The hand-held computer 20includes a processing unit 34 coupled to the touch screen display 32 anda memory 44. The memory 44 comprises a conventional disc, read-onlymemory, and a random access memory for storing the event report program48 of the present invention, as well as a set of patient records 46 anda set of master tables 50. The set of patient records 46 consist of arecord 46 for each patient treated during an emergency incident. Eachpatient record 46 includes all of the events and related informationrecorded by the emergency service provider, including but not limited topersonal and background information for the patient, a clinicalnarrative of the incident, and each event recorded during the incident.The master tables 50, on the other hand, store patient independentinformation, such as address books, drug guidelines and other referencematerials commonly used by emergency service providers in treatment ofpatients and made available by the event reporting program 48 asdescribed in more detail below. In addition, the master tables 50 storevarious menus from which the emergency service provider may selectpredefined events and other information for recordation during theincident. Consequently, the emergency service provider need not manuallyinput each event as it occurs.

[0024] Those of ordinary skill in the art will appreciate that due tothe limited memory space in hand-held computer 20, the patient records46 containing the patient and incident information input by theemergency service provider, and the master tables 50 containing patientindependent information are stored in simple tables in memory 44 of thehand-held computer 20. If the event reporting program 48 were installedin a more sophisticated device, such as a personal computer or laptopcomputer, with greater memory capabilities, the patient records 46 andmaster tables 50 would be stored in a database capable of being accessedand manipulated by a wider variety of database tools. In someembodiments of the present invention, the database in which the patientrecords are stored comprises a relational database which can be moreflexibly accessed and manipulated.

[0025] As also shown in FIG. 2, the processing unit 34 is coupled to akeyboard 30 and a microphone/speaker 40 which may be used in addition toor instead of the touch screen 32 and pen 22 to input events and relatedincident information and control the event reporting program 48. As willbe described in more detail below, each event input by an emergencyservice provider via the touch screen pen 22 and display 32, themicrophone/speaker 40, and/or the keyboard 30 is stored in a patientrecord 46 in memory 44 with the time the event is input as provided by aclock 36 coupled to the processing unit 34.

[0026] Finally, the hand-held computer 20 includes an external interface42 through which the hand-held computer 20 may transfer recorded eventsand related information to and from the hand-held computer 20 and anexternal device. For example, in some embodiments of the presentinvention, the hand-held computer 20 may import events and relatedinformation through the external interface 42 from a remoteComputer-Aided Dispatch (CAD) system or from another medical device suchas a defibrillator. Conversely, the hand-held computer 20 may exportevents and related information stored in the patient records 46 andmaster tables 50 of the memory 44 through the external interface 42 to aremote device, such as a computer located at the hospital to which thepatient will be admitted. In one actual embodiment of the presentinvention, the external interface 42 comprises a modem which willestablish a communications link with the external device with which thehand-held computer is communicating. In yet other embodiments of thepresent invention, the external interface 42 comprises serial input andoutput ports directly connected to the external device with which thehand-held computer is communicating.

[0027] Now that the components of the hand-held computer 20 which arenecessary for implementing the event reporting program 48 of the presentinvention have been described, the event report program 48 itself willbe described in further detail. FIG. 3 illustrates the logic used by theevent reporting program 48 to record and report an emergency incident.It will be appreciated that the event reporting program 48 willtypically be started up by the emergency service provider on route tothe emergency incident or soon after arriving. Accordingly, the eventreporting program 48 begins in a block 200 and proceeds to a block 202in which the emergency service provider uploads a user identification,e.g., the name of the emergency service provider, and an identificationnumber for the incident. More specifically, the event reporting program48 produces an open incident window 52 on the display 32 of thehand-held computer 20 as shown in FIG. 4 through which the emergencyservice provider enters his or her name in a user identification field54, as well as the incident identification number in an incidentidentification field 56. It will be appreciated that the user'sidentification and the incident's identification number may be enteredby the emergency service provider using the keyboard 30 of the hand-heldcomputer 20 or voice prompting via the speaker/microphone 24, or byselecting the provider identification and the incident identificationfrom predefined menus. Once the necessary information has been input,the emergency service provider may continue with the event reportingprogram 48 by selecting a begin button 58.

[0028] Returning to FIG. 3, the event reporting program 48 proceeds to ablock 20 in which the emergency service provider begins recording eventsthat occur during the emergency incident. As will be described in moredetail below, the emergency service provider may record events whichoccur during the emergency incident using a series of windows producedby the event reporting program 48. The emergency service provider mayalso input additional information regarding the incident and the patientbeing treated. Following the incident, the emergency service providermay further process the events and related information that wererecorded during the incident in order to produce a more accurate runreport regarding the entire incident. In this regard, the eventreporting program 48 post-processes the events and related informationin a block 206. Once post-processing is complete, the event reportingprogram 48 ends in a block 208.

[0029] Returning to block 204, once the name of the service provider andthe identification number for the incident have been uploaded via theopen incident window 52, the event recording component of the eventreporting program 48 is instigated. The logic implemented by the eventrecording component of the program is shown in more detail in FIG. 5.The logic begins in a block 210 and proceeds to a block 212 where the“arrive patient” data for the incident is automatically stored in thepatient's record 46. In this regard, the event reporting program 48generates an event recorder window 60 as shown in FIG. 6A. The eventrecorder window 60 includes an event summary 62 which displays an eventrecord 68 for each event recorded by the emergency service providerduring an incident. Each event record 68 essentially comprises anevent/time pair, i.e., a description of the event itself and a time atwhich the event occurred. The description of the event itself can bebroken down into a common descriptor for the event, e.g., “arrivepatient” or “shock,” and additional detail for the event, e.g., “200J”for a shock event. Similarly, the time at which the event occurred maybe broken down into a time as read by the clock 36 at which the eventwas input by the emergency service provider (which should approximatethe time the actual event occurred within one minute if promptly inputby the emergency service provider), and an expected time for the eventto occur (which can be determined based on the time registered by theclock 36 and a time interval during which the event is expected to occuraccording to EMS and other accepted guidelines). As will be described inmore detail below, the emergency service provider can input a treatmentprotocol comprising a collection of predefined events (wherein eachpredefined event is associated with an expected time of occurrence),rather than input events individually, one-by-one as they occur. It willbe appreciated that each event record 68 and thus, each event/time pair,may include either an actual time, an expected time, or both. Eachevent/time pair must also include an event description, althoughadditional detail is not always required. Each event record 68comprising an event/time pair is represented in the event summary 62with a time field 68 a containing the time as registered by the clock 36at which the emergency service provider input the event; an expectedtime field 68 b containing an automatically logged time at which theevent is expected to occur during the incident; an event field 68 ccontaining a common descriptor for the event input by the emergencyservice provider; and a detail field 68 d containing additional detailand information regarding the event. As will be described in more detailbelow, an event record 68 will be added to the event summary 62contained in the event recorder window 60 as each event occurs and isinput by the emergency service provider during the incident.

[0030] As mentioned above, there are a number of ways in which theemergency service provider may record events and related information viathe event recorder window 60. For example, the emergency serviceprovider may add individual events and related detail by inputting anevent descriptor in an event selection field 64 and inputting relatedinformation in a detail field 66 in the event recorder window 60. Inaddition, the emergency service provider may select a treatmentprotocol, i.e., a predefined set of events, to the event summary window62 from the protocol selection field 70. Finally, the emergency serviceprovider can initiate a variety of tools from the event recorder window60 to aid in treatment of the patient during the incident. For example,the emergency service provider may initiate an address book tool byselecting an address book button 72 a; a drug guide tool by selecting adrug guide tool button 72 b; a medication tool by selecting a medicationtool button 72 c; a narrative tool by selecting a narrative tool button72 d; a stopwatch tool by selecting a stopwatch tool button 72 e; and adosage calculating tool by selecting dosage tool button 72 f.

[0031] Returning to block 212 of FIG. 5 and the arrival of the emergencyservice provider to the emergency incident, it will be appreciated thatthe event reporting program 48 automatically adds an event record 68 tothe event summary 62 to record the arrival of the emergency serviceprovider to the patient. More specifically, an event record 68 is addedto the event summary 62 as soon as the emergency service provider beginsthe event recordation component of the program from the open incidentwindow 52. The expected time for the arrive patient event is stored inthe expected time field 68 b of the event record 68. It will beappreciated that the expected time entered in this field is the timecalculated by the event reporting program 48 based on the actual timeprovided by the clock 36 and a time interval during which the emergencyservice provider is reasonably expected to arrive at the patient. Itwill be appreciated that the calculation of this time interval willdepend on the acceptable emergency response intervals promulgated by theprovider's supervisory EMS. The event descriptor, i.e., “arrive patient”is also automatically entered in the event field 68 c of the eventrecord 68. The event record is correspondingly stored in the patientrecord 46 for the patient in memory 44. As will be described in moredetail below, event records 68 can be further modified, added or deletedby the emergency service provider as necessary to provide a moreaccurate run report for the emergency incident. In addition, eventrecords 68 may be exported to other devices for further processing andrecord keeping.

[0032] Returning to FIG. 5, once the arrive patient event record hasbeen stored and displayed as part of the event summary 62, the emergencyservice provider is free to add additional events as they occur duringthe incident, add treatment protocols as the emergency service providerdeems necessary, and initiate the various tools described above asappropriate. In this regard, the event recording program 48 proceeds toa decision block 214 where it determines if the emergency serviceprovider has selected to add, modify or delete an event record 68 fromthe event recorder window 60. If so, the emergency service provider mayadd, edit, or delete an entire event, the actual time associated with anevent, or the detail associated with an event in a block 216. The eventrecorder windows 60 associated with such actions are shown in moredetail in FIGS. 6B-6D.

[0033] Referring to FIG. 6B, the emergency service provider may open anevent menu 76 by tapping the touch screen pen 22 on the arrow of theevent selection field 64. The emergency service provider may thenhighlight the desired event descriptor from the menu of events displayedin the event menu window 76 using the touch screen pen 22. For example,if the next event in the incident that occurs is the measurement of thepatient's blood pressure, the emergency service provider may select theblood pressure event descriptor, i.e., “BP,” from the event menu 76 byeither manually using the touch screen pen 22 or via voice prompt usingthe speaker/microphone 24. The blood pressure event descriptor, “BP”,will then appear in the event selection field 64 as shown in FIG. 6B.The emergency service provider then may input additional detailregarding the blood pressure event either via the keyboard 30 or thespeaker/microphone 24. More specifically, the emergency service providermay input the systolic and diastolic pressures measured from the patientin a detail entry field 66. As noted above, the menu of events displayedin the event menu window 26 is stored in memory 44 in the master tables50. If the displayed menu of events does not include the event desiredby the emergency service provider, it will be appreciated that theprovider may simply input the desired event descriptor using thekeyboard 30 or via voice prompt using the speaker/microphone 24. Ifvoice prompting is used, the actual voice recording may be stored inmemory 44 for later retrieval, reference, and/or transcription.

[0034] As shown in FIG. 6C, once the event selection field 64 andperhaps also, the detail entry fields 66 have been completed by theemergency service provider, the event reporting program 48 automaticallyadds an event record 68 containing the corresponding event/time pair tothe event summary 62 as shown in FIG. 6D. The event record 68 includesthe time at which the blood pressure was measured, i.e., the timeregistered on the hand-held computer's clock 36 when the blood pressureevent was selected, in the event time field 68 a of the event record 68.The event descriptor, “BP,” is inserted in the event field 68 c of theevent record 68; and the event detail, i.e., the measured systolic anddiastolic pressures, are inserted in the detail field 68 d of the eventrecord 68. Those of ordinary skill in the art will appreciate that forevery event descriptor selected by the emergency service provider fromthe event menu 76 or input manually by the provider, a similar eventrecord 68 will be added to the event summary 62. Further, it will beappreciated that the event record 68 is stored in the patient's record46 in memory 44 of the hand-held computer 20 for post-processing or forexport to another device.

[0035] Returning to block 216 of FIG. 5, in addition to adding an eventrecord 68 to the event summary 62, the emergency service provider canalso edit or delete an event record 68. More specifically, if theemergency service provider wishes to modify an already added eventrecord 68, the emergency service provider need merely highlight theappropriate field 68 a-68 d of the event record using the touch screenpen 22 or using voice input via the speaker/microphone 24 in order tomodify the data contained in that field. For example, if the emergencyservice provider wishes to add additional detail in the detail field 68,the emergency service provider can merely tap the data entry field 68 dwith the touch screen pen 22 and then add, modify or delete theinformation contained therein using the keyboard 30 of the hand-heldcomputer 20 or voice prompting via the speaker/microphone 24. The sameprocedure can be followed to modify, add or delete any of the datastored in any of the other fields 68 a, 68 b, and 68 c. Further, if theemergency service provider wishes to delete an event record in itsentirety, the emergency service provider must merely highlight theentire record and enter the delete key (not specifically shown)contained on the keyboard 30 of the hand-held computer. As will bedescribed in more detail below, the emergency service provider also hasthe option of editing, modifying, or deleting event records after theincident during post-processing.

[0036] Referring once again to FIG. 5, once the emergency serviceprovider has added, edited or deleted an event record 68, the logicreturns to decision block 214 where the emergency service provider isagain given the opportunity to add, modify or delete an event and/or itsassociated time stamp and detail. Accordingly, as treatment of thepatient progresses during an emergency incident, the emergency serviceprovider can record each event which occurs during treatment using theevent reporting program 48. However, returning to decision block 214,the emergency service provider may, in fact, choose not to add anindividual event. Rather, the provider may choose to record an entiretreatment protocol as previously mentioned. In this regard, the eventreporting program 48 determines in a decision block 218 if the emergencyservice provider has selected a treatment protocol from the treatmentprotocol field 70 of the event recorder window 60. If so, the eventreporting program 48 automatically adds the treatment protocol to theevent summary 62 in a block 220.

[0037] The event recorder window 60 produced by the event recordingprogram 48 when a treatment protocol is added is shown in more detail inFIGS. 6E and 6F. Referring to FIG. 6E, the emergency service providermay select a treatment protocol by opening a protocol menu 78 andhighlighting the desired protocol. For example, if the patient isexperiencing cardiac arrest, the provider may wish to record a treatmentprotocol for cardiac arrest which includes all of the events one wouldmost likely expect to occur during treatment of such a condition, e.g.,CPR, delivery of a therapeutic shock, etc., and the time at which eachof these events are expected to occur. Consequently, the emergencyservice provider need not record each event associated with treatment ofthe cardiac arrest one-by-one, and is free to give his or her fullattention to the patient. However, as will be described in more detailbelow, the provider does have the ability to modify and delete any ofthe events added by selecting a protocol as necessary to create a moreaccurate run report. In addition, it will be appreciated from thedescription above that the provider can also record additional eventsthat may have occurred during treatment but were not included in theselected protocol.

[0038] As shown in more detail in FIG. 6F, once the desired protocol hasbeen selected (e.g., “Cardiac Arrest”) a predefined collection of eventrecords 68 associated with treatment in accordance with the selectedprotocol is entered in the event summary 62. Again, using the cardiacarrest example, the first event that typically occurs in the treatmentof cardiac arrest is the performance of CPR. Accordingly, the eventreporting program 48 enters an event record 68′ for CPR, wherein theevent record includes the time at which the emergency service provideris expected to perform CPR in the expected time field 68 b. In addition,the event reporting program will insert a descriptor for the event,i.e., “CPR”, in the event field 68 c. As yet another example, subsequentto performing CPR and monitoring the patient, the provider is expectedto deliver a therapeutic shock to the patient. Accordingly, thetreatment protocol includes an event record 68″ containing the expectedtime of the shock in expected time field 68 b, an event descriptor forthe shock in event field 68 c, and additional detail regarding theshock, e.g., 200J, in detail entry field 68 d. In accordance with yetother aspects of the present invention, once the expected time stored inthe expected time field 68 b for each protocol related event recordexpires, the event reporting program issues an audible alarm via thespeaker/microphone 24 and/or a visual alarm via the display 32 to notifythe emergency service provider that the expected treatment event must beadministered.

[0039] As is apparent from the logic illustrated in FIG. 5, once thetreatment protocol has been added in a block 220, the logic returns todecision block 214 where it determines if the emergency service providerhas elected to add, edit or delete an event record 68. It follows thatonce a treatment protocol has been added to the event summary 62, theemergency service provider can continue to add additional event records58 to the event summary 62, or can modify or previously recorded eventrecords, including those added in association with a treatment protocol.Thus, if the emergency service provider modifies the treatment of thepatient in any way from that automatically defined by the protocol, theemergency service provider is capable of modifying or deleting theappropriate event records, thus making for a more accurate incident runreport.

[0040] Returning to FIG. 5, in addition to adding, editing or deletingevent records 68 individually and in groups by selection of a treatmentprotocol, the emergency service provider may also initiate tools fromthe event recorder window 60 to assist him or her in treatment of thepatient. In this regard, the logic proceeds to a decision block 222where it determines if the emergency service provider has initiated atool by selecting one of the tool buttons 72 a-72 f from the eventrecorder window 60. If so, the selected tool is implemented by the eventreporting program 48 in block 224. The event recorder windows 60associated with each tool are shown in more detail in FIGS. 6G-6L.

[0041] As shown in FIG. 6G, if the emergency service provider selectsthe address book button 72 a, an address book window 80 is generated bythe event reporting program 48. From the address book window 80, theemergency service provider may open an address menu 84 and select adesired address or telephone number using the touch screen pen 22. Forexample, if the emergency service provider needs the telephone numberfor a particular hospital, the emergency service provider may select thephone number for the desired hospital from the address menu 84.

[0042] If the emergency service record 68 provider selects the drug toolbutton 72 b, a drug guideline window 86 is generated by the eventreporting program 48 as shown in FIG. 6H. The emergency service providermay then retrieve from the master tables 50 stored in memory 44 of thehand-held computer, the guidelines for any drug with which the emergencyservice provider desires to treat the patient. The emergency serviceprovider merely selects the desired drug from a drug menu (not shown)opened by tapping an arrow in a drug identification field 88 of the drugguideline window 86 with the touch screen pen 22 or by voice command.The associated information is retrieved from the master tables 50 storedin memory 44 and displayed in the drug guideline window 88. Onceinformation regarding the desired drug has been retrieved and displayed,the emergency service provider may opt to calculate an appropriatedosage for the drug by selecting a dose button 89. The dosagecalculation tool and the dosage calculation window 118 generated by theevent reporting program 48 will be described in more detail below.

[0043] If the emergency service provider selects the patient medicationsbutton 72 c in the event recorder window 60, a patient medicationswindow 90 is generated by the event reporting program 48 as shown inFIG. 6I. The emergency service provider may then select any medicationthe patient is currently taking from a medication menu 94 (supplied bythe master table 50). This medication information is then stored inmemory 44 in the patient's record 46.

[0044] If the emergency server provider selects the narrative button 72d, the event reporting program 48 generates a narrative story window 96on the display 32 of the hand-held computer 20 as shown in FIG. 6J. Thenarrative story window 96 includes a narrative field 98 into which theemergency service provider may directly input information in a narrativeformat. It will be appreciated that the emergency service provider mayinput the narrative using the keyboard 30 of the hand-held computer 20.However, in other embodiments of the present invention, in which thehand-held computer is equipped with a speaker/microphone 24 and voicerecognition software, the emergency service provider may simply speakinto the microphone 24 in order to input the narrative. If voiceprompting is used, the emergency service provider may simply select arecord button 100 using the touch screen pen 22 to initiate recording ofhis voice via the speaker/microphone 24. If the emergency serviceprovider wishes to play back the recorded narrative, the emergencyservice provider may select the play button 102 and if the emergencyservice provider wishes to erase any of the narrative, the emergencyservice provider may select the erase button 104. Once the narrative hasbeen recorded, the emergency service provider may exit the narrativestory window 96 by selecting the close button 103. Once completed, thetext of the narrative is stored in the patient's record 46 in memory 44of the hand-held computer 20.

[0045] If the emergency service provider selects the stop watch toolbutton 72 e, a stop watch window 106 is generated by the event reportingprogram 48 as shown in FIG. 6K. The stop watch tool allows the emergencyservice provider to time events, e.g., to time a particular treatmentmeasure. For example, if the patient's pulse must be taken for sixtyseconds, the emergency service provider may reset the stop watch tosixty seconds using the reset button 108 and start the countdown of thestop watch from sixty seconds using the start button 110. When the stopwatch expires, the emergency event program generates an audible tone viathe speaker/microphone 24 of the hand-held computer 20 and/or via avisible message generated on the display. The emergency service providercan stop the stop watch at any time using the stop button 112.

[0046] Finally, if the emergency service provider selects the dosagecalculation button 72 f from the event recorder window 60, the eventreporting program 48 generates a dosage/infusion calculator window 114as shown in FIG. 6L. Accordingly, the emergency service provider mayselect the desired medication from a medication menu (not shown) opened,for example, by tapping an arrow in a medication field 116 of thedosage/infusion calculator window 114. The emergency service providermay then input the information necessary for calculating the appropriatedosage for the selected medication in a dosage window 118. The providermay also calculate an infusion rate for the selected medication byinputting the necessary information in an infusion window 120. Once theappropriate information for calculating the dosage and/or infusion hasbeen input by the provider, the emergency service provider may select acalculate button 122 to initiate calculation of the appropriatedosage/infusion. Those of ordinary skill in the art will recognize thatthe appropriate formulas for calculating dosage/infusion are well knownin the art and thus, need not be described in more detail herein. If theemergency service provider wishes to calculate the dosage/infusion foranother medication, the emergency service provider need only select theclear button 124 in the dosage/infusion calculator window 114. If theemergency service provider desires more information regarding theselected medication, the emergency service provider may select theinformation button 126 from the dosage/infusion calculator 114. Inresponse, the event reporting program 48 will generate a drug guidelinewindow 86 as shown in FIG. 6H and as associated with the drug guidelinebutton 72 b for the selected medication. Finally, as noted above, theemergency service provider may proceed to the dosage/infusion calculatorwindow 118 via the drug guideline window 86 shown in FIG. 6H byselection of the dose button 89 in the drug guideline window 86.

[0047] Returning to FIG. 5, once the tool selected by the emergencyservice provider has been implemented in a block 224, the logic returnsto decision blocks 214, 218 and 222 as appropriate depending on theselections made by the emergency service provider. It follows from theabove discussion that the emergency service provider may add eventrecords, add treatment protocols and initiate tools in whatever order heor she deems necessary until the incident comes to a conclusion. At thattime, the emergency service provider may select an end incident button74 from the event recorder window 60 and the event recording componentof the event reporting program 48 will be terminated. Accordingly, theresult of a decision block 226 in FIG. 5 is positive, and the logic endsin a block 228.

[0048] Returning to FIG. 3, once the event recording component of theevent reporting program 48 has been completed in a block 204, thepost-processing component of the event reporting program begins in ablock 206. It will be appreciated that the post-processing of the eventsand related information recorded during the incident may occur at anytime. For example, post-processing may occur while the emergency serviceprovider is still at the scene of the incident, or after the providerdelivers the patient to an emergency care facility. As will be describedin more detail below, regardless of when post-processing occurs, theemergency service provider is allowed by the event reporting program 48to add, modify and delete previously recorded events; add eventsrecorded by external devices; add, modify and delete informationregarding the patient; edit the previously recorded narrative; generatea complete incident run report; and/or export events and relatedinformation to external devices.

[0049] The logic employed by the post-processing component of the eventreporting program 48 to post-process events is shown in more detail inFIG. 7. The logic begins in a block 230 and proceeds to a block 232where the event reporting program 48 generates a post-event window 128on the display 32 of the hand-held computer 20. The post-event window128 generated by the event reporting program is shown in more detail inFIG. 8A. Similar to the event recorder window 60, the post-event window128 includes an event summary 130 which displays a post event record 148corresponding to each event record 68 that was recorded by the emergencyservice provider during the incident. Accordingly, each post eventrecord 148 includes a time field 148 a, an expected time field 148 b, anevent field 148 c and a detail entry field 148 d. However, the postevent record 148 also includes a source field 148 e which identifies thesource of the recorded event. For example, if the event was recorded bythe emergency service provider, the event reporting program 48automatically enters the user identification of the emergency serviceprovider in the source field 148 e. If the event was recorded by a CADsystem and imported to the event reporting program 48, “CAD,” isidentified as the source of the post event record 148. Similarly, if theevent was imported from an external device, such as a LIFEPAK® 12defibrillator manufactured by Physio-Control Manufacturing Corporationof Redmond, Wash., the source field would identify the external device,e.g., “LP12,” as the source of the post event record 148.

[0050] In addition to the event summary 130, the post-event window 128also includes a device event button 132, a CAD event button 134, anarrative data button 136, an additional data button 138, a narrativeedit button 140, a run report button 142, an export data button 143, anew case button 144 (for post processing another incident), and an exitbutton 146. The actions taken by the event reporting program 48 as eachof these buttons are selected by the emergency service provider will nowbe described in more detail.

[0051] Returning to FIG. 7, once the post-event window 128 has beendisplayed by the event reporting program 48 in a block 232, the logicproceeds to a decision block 234 where it determines if the emergencyservice provider has elected to edit a post event record 148 byhighlighting a post event record 148 in the event summary 130. If so,the emergency service provider is allowed to edit the post event record148 in a block 236. More specifically, the event reporting program 48generates an event edit window 150 as shown in FIG. 8B. The emergencyservice provider can delete the highlighted post event record 48 byselecting a delete event button 15; modify the highlighted post eventrecord 148 by inputting the appropriate information in a modify eventfield 154; or insert a new post event record 148 immediately precedingthe highlighted record by inputting the appropriate information in aninsert new event field 156. When modifying an existing post eventrecord, the provider may add or edit the time of the event, thedescriptor for the event, and/or the detail associated with the event.The emergency service provider may then save the post event record 148in the patient's record 46 in memory 48 by selecting the save button151. Simultaneously, the corresponding post event record 148 is eitherdeleted from, modified in, or added to the event summary 130.

[0052] Returning to FIG. 7, if the emergency service provider does notwish to edit a post event record 148 or selects this option and does so,the logic proceeds to a decision block 238 where it determines if theemergency service provider has opted to add Computer-Aided Dispatch,“CAD,” events to the event summary 130 by selecting the CAD event button134 as shown in FIG. 8C. CAD events are those that are registered by anexternal CAD system, typically the CAD system that dispatched theemergency service provider to the incident. By establishing acommunications link between the hand-held computer 20 and a remote CADcomputer via the hand-held computer's external interface 42, theemergency service provider can download CAD events from the remote CADcomputer. Each CAD event consists of an event/time pair, which isformatted by the event reporting program as a post event record 148. Theevent reporting program 48 inserts the corresponding post event record148 in the event summary 130 in chronological order as shown in FIG. 8C.For example, when the emergency 911 call for the incident being reportedis received by a remote CAD computer, the remote CAD computer stores thetime of the phone call and an event descriptor for the phone call, i.e.,“Call 911,” in its own memory. After the 911 event/time pair isdownloaded (along with others) to the hand-held computer 20, it isinserted in the event summary 130 as post event record 148′. The timefield 148 a of the inserted post event record 148′ includes the timerecorded by the CAD computer for the 911 call; the event 148 c includesa brief descriptor for the 911 event, i.e., “Call 911”; and the sourcefield 148 e indicates that the source of the post event record 148′ is aCAD computer. It will be appreciated that whenever event/time pairs areimported from a CAD system or some other external device, the eventreporting program 48 will synchronize the imported event times with theclock 36 of the hand-held computer so that imported event times areproperly offset before added to the event summary 130.

[0053] Returning to FIG. 7, once the downloaded CAD event/time pairshave been incorporated into the event summary 130 as post event records148, the logic proceeds to a decision block 242 where it determines ifthe emergency service provider has elected to add device events to theevent summary 130 by selecting the device events button 132 as shown inFIG. 8D. More specifically, the event reporting program 48 detectswhether the emergency service provider has selected the device eventbutton 132 from the post-event window 128. If so, the logic proceeds toa block 244 where the device events are incorporated in the eventsummary 130. It will be appreciated that device events are similar toCAD events in that they are obtained from a remote device as anevent/time pair and incorporated into the event summary 130 as postevent records 148 in chronological order. Such devices may includemedical electronic devices used by the emergency service provider toadminister treatment to the patient during the incident, e.g., externaldefibrillators, non-invasive blood pressure instruments, etc., or otherremote computer systems, such as a mainframe computer located at thehospital to which the patient will be delivered. By establishing acommunication link with the external device via its external interface42, the hand-held computer 20 can download event/time pairs recorded bythe external device and insert them as post event records 148 in theevent summary 130. For example, if the external device is adefibrillator, such as the LIFEPAK® 12 defibrillator, the defibrillatorstores various event/time pairs relating to the treatment of thepatient's cardiac condition. For example, a defibrillator typicallystores an event/time pair including the measured heart rate for thetreated patient and the time at which the heart rate was measured. Whenthe device events button 132 is selected, the event/time pair for themeasured heart rate is downloaded from the defibrillator to thehand-held computer 20 and inserted in the event summary 130 as a postevent record 148″. Accordingly, event field 148 a includes the time atwhich the heart rate was measured; the event field 148 c includes thecommon descriptor for the event, i.e., “Heart Rate,” measured by thedefibrillator; the detail entry field 148 d includes the measured heartrate, i.e., 92; and the source field 148 e indicates that the source ofthe post event record 148″ is a LIFEPAK® 12 defibrillator.

[0054] Returning to FIG. 7, once the downloaded device event/time pairshave been incorporated in the event summary 130 as post event records148, the logic proceeds to a decision block 246 where it determines ifthe emergency service provider has elected to add patient data to thepatient's record 46 by selecting the additional data button 138 in thepost-event window 128 as shown in FIG. 8E. If so, the emergency serviceprovider further builds the patient's record 46 in a block 248 withinformation obtained via a patient information window 158 generated bythe event reporting program 48. The patient information window 158includes patient information fields 160 in which the emergency serviceprovider inserts personal information regarding the patient, such asname, age, weight, address, etc.; and incident information fields 164 inwhich the emergency service provider inputs information regarding theincident, such as its location and its outcome. It will be appreciatedthat the provider may input information in the patient informationfields 160 and the incident information fields 160 using the keyboard 30or the by speaking via the speaker/microphone 24. The newly addedpatient information is stored in the patient's record 46 in memory whenthe emergency service provider selects a save button 165 in the patientinformation window 158.

[0055] Once the new information has been stored in the patient's record46, the logic returns to a decision block 250 in FIG. 7 where itdetermines if the emergency service provider has elected to edit thenarrative previously recorded by him or her during the incident byselecting the narrative edit button 140 in the post-event window 128. Ifso, the emergency service provider is allowed to modify the narrativetext in a block 256. More specifically, the event reporting program 48produces a narrative story window 96 as shown previously n FIG. 6J,which includes the text of the previously recorded narrative.Accordingly, the emergency service provider may edit the text narrativeusing the keyboard 30 or alternatively, by voice prompting via thespeaker/microphone 24.

[0056] Once the emergency service provider has modified the text of thenarrative as desired, the logic returns in FIG. 7 to a decision block254 where it determines if the emergency service provider has elected toadd certain pieces of information from the narrative to the patient'srecord 46 by selecting the narrative data button 136 in the post-eventwindow 128. If so, the event reporting program 48 runs a narrativeparsing routine shown in more detail in FIG. 9 to identify desirablepieces of information from the narrative and add them to the patient'srecord 46.

[0057] The narrative parsing routine depicted in FIG. 9 examines thetext of the narrative previously recorded and perhaps edited by theemergency service provider for pieces of data that are commonly expectedto be recorded during an emergency incident, such as the age and/or sexof a patient, common symptoms for a patient, blood pressure of apatient, etc. By reviewing the text of the narrative for suchinformation and automatically adding the information to the patient'srecord 46, the emergency service provider eliminates the extra task ofinputting such information into the patient's records 46 manually.

[0058] Returning to FIG. 7, the narrative parsing routine begins in FIG.9 in a block 266 and proceeds to a block 268 in which the first word ofthe narrative text is read. In a decision block 270, the routinedetermines if the read word is equal to a narrative keyword stored in apredefined list of narrative keywords found in the master tables 50. Akeyword for purposes of the present invention is a word or term that iscommonly expected to appear in a clinical narrative, e.g., “years(s),”“male,” “female,” “pressure,” etc. If the first word read from thenarrative is'not equal to one of the keywords in the predefined list,the logic proceeds to a decision block 271 in which it determines if theend of the narrative has been reached, i.e., if the last word of thenarrative has been read. If so, the narrative edit routine ends in ablock 272. Otherwise, the next word in the narrative text is obtained ina block 273 and decision block 270 is repeated.

[0059] If the word obtained from the narrative is equal to one of thekeywords stored in the list of keywords, a modifier template for thekeyword is retrieved from the master tables 50 in a block 274. Eachkeyword in the list of keywords has a corresponding modifier templatestored in the master tables 50 which identifies a typical pattern inwhich a desired word, term, or number, i.e., “modifier,” is expected toappear in the text in association with the keyword. For example, if thekeyword obtained from the narrative is “year(s),” the common term ormodifier expected to appear with the keyword is an age for the patient.Consequently, the modifier template for the keyword identifies thefollowing pattern for the modifier and keyword:

[0060] x w/5 year(s) or

[0061] year(s) w/5 x

[0062] wherein the modifier, i.e., the age of the patient denoted the byvariable “x,” is expected to appear within the five words preceding thekeyword “year(s)” or within five words following the keyword “year(s).”

[0063] Once the modifier template for the key word has been retrieved ina block 274, the narrative text is scanned for the appropriate modifierthat matches the modifier template in a block 276. Using the aboveexample, the narrative text is scanned for the variable “x,” i.e., age,falling within the five words preceding or following the word “year(s).”Once the modifier matching the modifier template is located, avalidation rule is applied to the modifier in a block 278 to ensure thatthe modifier actually constitutes a desired or valid piece ofinformation to be inserted in the patient's record 46. Again, using theexample above, if the keyword obtained from the text of the narrative is“years(s),” the located modifier, i.e., the age of the patient, isvalidated against a rule requiring that the age be less than a maximumage permitted, e.g., 110. Yet other validation rules may require that alocated blood pressure modifier, e.g., 110/60, be less than a maximumsystolic pressure and greater than a minimum diastolic pressure, or thata located sex modifier of a patient be either male or female. Oncevalidated, the modifier is inserted into the patient's record 46 inmemory in a block 280. Those of ordinary skill in the art will recognizethat modifier templates and validation rules of virtually any type ornature may be implemented by the event reporting program 48.

[0064] Returning to FIG. 7, once the appropriate narrative data has beenparsed and added to the record 46 for the patient, the logic proceeds toa decision block 258 where it determines if the emergency serviceprovider has elected to run a complete report of the incident byselecting the run report button 142 in the post-event window 128. If so,a full run report as shown in FIG. 8F will be generated on the display32 of the hand-held computer from the information stored in thepatient's record. It will be appreciated that the run report may also beprinted, if desired. The full run report 164 includes an incident field166 which identifies the incident by identification number, location,etc., as stored in the patient record 46 for the treated patient; apatient field 168 which includes the personal and background informationstored in the patient record 46; and a narrative field 170 whichincludes the narrative previously edited and recorded by the emergencyservice provider. Finally, the run report 164 includes a complete eventsummary 172 that shows each of the event records 68 recorded by theemergency service provider and any remote devices or CAD systems.

[0065] After the full run report 64 has been displayed, the logicreturns to a decision block 260 in FIG. 7 where it determines if theemergency service provider has elected to export data recorded by theevent reporting program 48 to an external destination by selecting theexport data button 143 in the post-event window 128. If so, thehand-held computer 20 transfers the patient records 46 stored in memory44 to another device via its external interface 42 in a block 261. Inthe alternative, the hand-held computer 20 stores patient records 46 toa portable storage medium, such as a diskette, for physical transfer toanother device.

[0066] After export, the logic proceeds in FIG. 7 to a decision block262 where it determines if an exit signal has been received. Morespecifically, the logic determines if the emergency service provider hasselected the exit button 146 in the post-event window 128. If so, theevent reporting program ends in a block 264. If not, the emergencyservice provider can continue post-processing of the incident byselecting any of the available post-processing options and repeatingblocks 234 through 262.

[0067] While the preferred embodiment of the invention has beenillustrated and described, it will be appreciated that various changescan be made therein without departing from the spirit and scope of theinvention. For example, although the event reporting program 48 of thepresent invention described herein is used by an emergency serviceprovider in the context of medical treatment of a patient during anemergency incident, the present invention may be just as easily used ina multitude of other contexts. For example, the invention could be usedby a police officer in the context of an emergency criminal incident. Inthis case, the events recorded and tools initiated would relate to thearrest of a suspect, rather than medical treatment of a patient. Inaccordance with yet other aspects of the invention, a separate log maybe kept of all recorded, modified and deleted events for use in auditingthe final event summary 172 for inaccuracies. Finally, in yet otherembodiments of the present invention, a digital audio recorder may beused to record all of the emergency service provider's verbal inputsduring the entire incident along with their associated time stamps as anaudio event log. The audio event log could then be compiled andtranscribed into an event summary and run report following completion ofthe incident.

1. A method comprising: storing a plurality of treatment protocols, eachof the treatment protocols including a plurality of event records, andeach of the event records including information describing an event thatis expected to occur and a time that the event is expected to occurduring provision of treatment according to one of the treatmentprotocols; generating an incident record for a patient that includesinformation related to treatment of the patient during a medicalemergency; and including event records of one of the treatment protocolsthat was selected by a user from among the plurality of stored treatmentprotocols based on a condition of the patient within the incident recordfor the patient.
 2. The method of claim 1, further comprising modifyinga selected one of the event records of the selected protocol within theincident record based on input received from the user.
 3. The method ofclaim 2, in which the input describes a time that an event described bythe selected event record actually occurred, and modifying a selectedone of the event records comprises adding the time at which the eventactually occurred to the selected event record.
 4. The method of claim1, further comprising adding an additional event record to the incidentrecord based on input received from the user, the additional eventrecord including information that describes an event not associated withthe selected treatment protocol that occurred during treatment of thepatient.
 5. The method of claim 1, further comprising: receivinginformation that describes an event not associated with the selectedtreatment protocol that occurred during treatment of the patient from adevice; and adding an additional event record that includes the receivedinformation and information identifying the device that provided thereceived information to the incident record.
 6. The method of claim 5,in which the device comprises one of a computer-aided dispatch systemand an external defibrillator used to treat the patient during themedical emergency.
 7. The method of claim 5, in which the informationreceived from the device includes a time that the event occurred, themethod further comprising: adjusting the time based on a current timeindicated by a clock; and storing the adjusted time within theadditional event record.
 8. The method of claim 1, further comprising:receiving a narrative from the user; and including the narrative withinthe incident record.
 9. The method of claim 1, further comprising:receiving information relating to medications used by the patient fromthe user; and including the medication information within the incidentrecord.
 10. The method of claim 1, further comprising: storinginformation relating to a plurality of drugs, the information includingdosage information for the drugs; displaying information relating to oneof the drugs selected by the user; receiving information relating to thepatient from the user; and displaying a dosage calculated based on theinformation relating to the patient and the dosage information to theuser.
 11. The method of claim 1, further comprising: for one of theevent records included within the incident record, determining that therespective time that the respective event was expected to occur hasexpired; and issuing an alarm to alert the user of the expiration. 12.The method of claim 1, further comprising generating a report thatincludes information stored within the incident record.
 13. A devicecomprising: a memory to store a plurality of treatment protocols, eachof the treatment protocols including a plurality of event records, andeach of the event records including information describing an event thatis expected to occur and a time that the event is expected to occurduring provision of treatment according to one of the treatmentprotocols; and a processor to generate an incident record for a patientthat includes information related to treatment of the patient during amedical emergency, include event records of one of the treatmentprotocols that was selected by a user based on a condition of thepatient within the incident record for the patient, and store theincident record within the memory.
 14. The device of claim 13, furthercomprising a user input device, wherein the processor modifies aselected one of the event records of the selected protocol within theincident record based on input received from the user via the user inputdevice.
 15. The device of claim 14, in which the input describes a timethat an event described by the selected event record actually occurred,and the processor adds the time at which the event actually occurred tothe selected event record.
 16. The device of claim 13, furthercomprising a user input device, wherein the processor adds an additionalevent record to the incident record based on input received from theuser via the user input device, and the additional event recordincluding information that describes an event not associated with theselected treatment protocol that occurred during treatment of thepatient.
 17. The device of claim 13, further comprising an interface toallow the processor communicate with another device, wherein theprocessor receives information that describes an event not associatedwith the selected treatment protocol that occurred during treatment ofthe patient from the other device, and adds an additional event recordthat includes the received information and information identifying theother device to the incident record.
 18. The device of claim 17, inwhich the other device comprises one of a computer-aided dispatch systemand an external defibrillator used to treat the patient during themedical emergency.
 19. The device of claim 17, further comprising aclock, wherein the information that the processor receives from theother device includes a time that the event occurred, and the processoradjusts the time based on a current time indicated by the clock, andstores the adjusted time within the additional event record.
 20. Thedevice of claim 13, further comprising a user input device, wherein theprocessor receives a narrative from the user via the user input device,and includes the narrative within the incident record.
 21. The device ofclaim 13, further comprising a user input device, wherein the processorreceives information relating to medications used by the patient fromthe user via the user input device, and includes the medicationinformation within the incident record.
 22. The device of claim 13,further comprising: a user input device; and a display, wherein thememory stores information relating to a plurality of drugs, theinformation including dosage information for the drugs, and theprocessor displays information via the display, the information relatingto one of the drugs selected by the user via the user input device,receives information relating to the patient from the user via the userinput device, and displays a dosage calculated based on the informationrelating to the patient and the dosage information to the user via thedisplay.
 23. The device of claim 13, further comprising an alarm,wherein for one of the event records included within the incident recordthe processor determines that the respective time that the respectiveevent was expected to occur has expired, and activates the alarm toalert the user of the expiration.
 24. The device of claim 13, in whichthe processor generates a report that includes information stored withinthe incident record.
 25. A computer-readable medium comprisinginstructions that cause a programmable processor to: generate anincident record for a patient that includes information related totreatment of the patient during a medical emergency; receive input froma user selecting one of a plurality of treatment protocols stored in amemory based on a condition of the patient, each of the treatmentprotocols including a plurality of event records, and each of the eventrecords including information describing an event that is expected tooccur and a time that the event is expected to occur during provision oftreatment according to one of the treatment protocols; and include eventrecords of the selected one of the treatment protocols within theincident record for the patient.
 26. The computer-readable medium ofclaim 25, further comprising instructions that cause a programmableprocessor to modify a selected one of the event records of the selectedprotocol within the incident record based on input received from theuser.
 27. The computer-readable medium of claim 26, in which the inputdescribes a time that an event described by the selected event recordactually occurred, and the instructions that cause a programmableprocessor to modify a selected one of the event records compriseinstructions that cause a programmable processor to add the time atwhich the event actually occurred to the selected event record.
 28. Thecomputer-readable medium of claim 25, further comprising instructionsthat cause a programmable processor to add an additional event record tothe incident record based on input received from the user, theadditional event record including information that describes an eventnot associated with the selected treatment protocol that occurred duringtreatment of the patient.
 29. The computer-readable medium of claim 25,further comprising instructions that cause a programmable processor to:receive information that describes an event not associated with theselected treatment protocol that occurred during treatment of thepatient from a device; and add an additional event record that includesthe received information and information identifying the device thatprovided the received information to the incident record.
 30. Thecomputer-readable medium of claim 29, in which the device comprises oneof a computer-aided dispatch system and an external defibrillator usedto treat the patient during the medical emergency.
 31. Thecomputer-readable medium of claim 29, in which the information receivedfrom the device includes a time that the event occurred, the mediumfurther comprising instructions that cause a programmable processor to:adjust the time based on a current time indicated by a clock; and storethe adjusted time within the additional event record.
 32. Thecomputer-readable medium of claim 25, further comprising instructionsthat cause a programmable processor to: receive a narrative from theuser; and include the narrative within the incident record.
 33. Thecomputer-readable medium of claim 25, further comprising instructionsthat cause a programmable processor to: receive information relating tomedications used by the patient from the user; and include themedication information within the incident record.
 34. Thecomputer-readable medium of claim 25, further comprising instructionsthat cause a programmable processor to: store information relating to aplurality of drugs, the information including dosage information for thedrugs; display information relating to one of the drugs selected by theuser; receive information relating to the patient from the user; anddisplay a dosage calculated based on the information relating to thepatient and the dosage information to the user.
 35. Thecomputer-readable medium of claim 25, further comprising instructionsthat cause a programmable processor to: for one of the event recordsincluded within the incident record, determine that the respective timethat the respective event was expected to occur has expired; and issuean alarm to alert the user of the expiration.
 36. The computer-readablemedium of claim 25, further comprising instructions that cause aprogrammable processor to generate a report that includes informationstored within the incident record.